1. Field of the Invention
This invention relates to a method and apparatus for facilitating communication between virtual machines (VMs), and more particularly, this invention relates to a method and apparatus for facilitating communication between VMs hosted in the same physical machine.
2. Description of the Related Art
Virtualization and multi-core techniques are being widely used in information technology. Virtualization techniques can isolate VMs (virtual machines) from the detail of their underlying host hardware platform, and therefore can detect migration, separation and integration of VMs. On this basis, virtualization techniques can utilize system resources efficiently and reduce the total cost of basic computer architecture. More specifically, virtualization technique can reduce the total cost of hardware platform and software management, as well as reduce the operation cost, while at the same time, enhance system availability, improve system scalability, and increase system reliability and system flexibility by ensuring resources for the key applications.
On the other hand, the development of multi-core techniques enable processors to extend from the original single core to dual-, quad-, eight-core chips, to the latest chips with tens or even hundreds of cores. The heterogeneous multi-core approach alters the multi-core architecture from traditional homogeneous design to heterogeneous design of “master core+slave processors”, which provides excellent performance especially for processing multimedia, recognition and networking applications. The processor performance has been improved greatly along with the development of multi-core techniques.
To better utilize processor resources and resource integration, a physical machine with strong processing ability can usually host a plurality of VMs. FIG. 1 illustrates a plurality of VMs in one physical machine. As shown in the figure, four VMs are hosted in the same physical machine. These four VMs have their own operating system and applications installed, and execute their own processing just like four actual computers. Through a virtualization layer between VMs' operating system and the hardware platform, multiple VMs can share the actual hardware resources of the physical machine, such as CPU, memory, NIC, etc. Like actual computers, communication and data transfer are necessary between these VMs to execute target jobs. In the following, the communication process between VMs in the existing technology will be explained, taking a popular open-source virtualization product Xen (http://www.xen.org/) as an example.
FIG. 2 is a block diagram of the Xen network virtualization system. As shown in FIG. 2, besides a plurality of VMs 1-n, Xen network system also contains two key components, the hypervisor and the driver domain. Xen hypervisor is located below the guest operating systems of all VMs and above the hardware. It abstracts the underlying physical hardware, takes charge of CPU scheduling and memory allocation for each VM, and controls the shared runtime environment, enabling each VM to run as if it were running natively on the hardware. To detect external connection and communication, the VMs must share the I/O devices in the hardware platform. These shared I/O devices are controlled by a special I/O domain, called driver domain in Xen. Specifically, the driver domain runs a modified version of Linux that uses native Linux device drivers to manage physical I/O devices. VMs can communicate with physical I/O via the driver domain.
To communicate with the driver domain and the physical I/O devices, each VM is given a virtual I/O device, which is controlled by a special device driver, called the front-end driver. Accordingly, there is a plurality of back-end drivers in the driver domain that communicates with the corresponding front-end driver. The back-end drivers are connected to the physical NIC (network interface card) by an Ethernet bridge within the driver domain. The following is a detailed description of the steps of transmitting and receiving data packet by a VM in Xen system.
When a VM transmits a packet, the packet is first copied from the front-end driver in the VM to the back-end driver in the driver domain. Then, in the driver domain, the packet is routed through the Ethernet bridge to the physical NIC's device driver. The packet is then packed and queued by the physical NIC's device driver for transmission on the network interface as if it were generated normally by the operating system within the driver domain.
When a VM receives a packet, the physical NIC first generates an interrupt, which is captured by the interrupt dispatch unit in the hypervisor and routed to the NIC's device driver in the driver domain as a virtual interrupt. Then the NIC's device driver transfers the packet to the Ethernet bridge, which routes the packet to the appropriate back-end driver. The back-end driver then copies the packet to the front-end driver in the target VM. Once the packet is transferred to the target VM, the back-end driver requests the hypervisor to send an additional virtual interrupt to the target VM notifying it of the new packet. Upon receiving the virtual interrupt, the front-end driver of the VM delivers the packet to the VM's network stack as if it had come directly from a physical device.
Another popular virtualization product VMWare (http://www.vmware.com/) also adopts a similar VM communication approach, transmitting and receiving packets alike. Moreover, VMWare introduces a virtual Ethernet switch between VMs and the physical adapter to facilitate networking.
Through the above-described packet transmitting and receiving approach, a VM can detect communication with other VMs. The physical host of the target VM is not differentiated in the above approach, i.e., the communication between any two VMs needs to go top-down from one VM's front-end driver via the back-end driver to the physical NIC, and then come bottom-up from the physical NIC via the hypervisor and the driver domain to the other VM. In such a process, a packet is copied at least twice between VMs and the physical machine and is also packed in transmitting and unpacked in receiving. Because of these unnecessary operations, this approach is not efficient, especially for VMs in the same physical machine. For VMs in the same physical machine, the communication between VMs only involves data transfer within the physical machine, not necessarily via the NIC. Therefore, the existing communication technique needs to be improved—that is, an improvement to the communication method between VMs, especially between VMs in the same physical machine, is needed to increase the communication efficiency by avoiding unnecessary operations and optimizing system resources.